docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/transform.mdx (1)

10-10: Same Icon component consideration applies here.

As with other documentation files, verify that the Icon component usage is compatible with Docusaurus MDX processing.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/items/check.mdx (1)

10-12: Same permalink drift issue as other MDX files

Update link generation to use commit SHAs or drop line anchors to keep docs stable over time.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/node/constants.mdx (1)

1-4: Use the standard Docusaurus front-matter key sidebar_label instead of sidebarTitle.

sidebarTitle is not recognised by Docusaurus v2; the expected key is sidebar_label.
Switching prevents the page from being hidden in the generated sidebar.

-title: constants
-sidebarTitle: constants
+title: constants
+sidebar_label: constants

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/cli.mdx (1)

1-4: Align front-matter with Docusaurus conventions.

Same comment as above – replace sidebarTitle with sidebar_label to guarantee proper sidebar rendering.

-title: cli
-sidebarTitle: cli
+title: cli
+sidebar_label: cli

docs/docs/python-sdk/sdk_ref/infrahub_sdk/playback.mdx (2)

1-4: Sidebar label key mismatch.

Update the key for consistency:

-title: playback
-sidebarTitle: playback
+title: playback
+sidebar_label: playback

---

6-25: Add a brief module & class description for better discoverability.

The page jumps straight into signatures. Two short sentences explaining what infrahub_sdk.playback does and typical JSONPlayback use-cases (e.g., “record/replay HTTP traffic for offline tests”) will greatly help readers.

No code diff provided since the text can be placed directly after the H1.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/transfer/exceptions.mdx (2)

1-4: Update front-matter key.

-title: exceptions
-sidebarTitle: exceptions
+title: exceptions
+sidebar_label: exceptions

---

8-18: Consider adding one-line summaries for each exception.

Readers benefit from seeing at a glance why each custom exception exists (e.g., file-already-exists vs. invalid namespace).
Example:

### `TransferError`
_Base class for all transfer-related errors._

docs/docs/python-sdk/sdk_ref/infrahub_sdk/object_store.mdx (2)

1-4: Use sidebar_label for sidebar entry.

-title: object_store
-sidebarTitle: object_store
+title: object_store
+sidebar_label: object_store

---

10-42: Provide high-level context & return-value notes.

A short paragraph describing what an “Object Store” is and clarifying what the upload method returns (e.g., signed URL, handle, etc.) will improve clarity.

Also, consider grouping async vs sync variants explicitly so users understand when to pick each.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/exceptions.mdx (2)

60-64: Copy-paste description does not match the exception.

InvalidResponseError inherits from Error but the description “Raised when an object requires an initialization step before use” is clearly for UninitializedError. Update the sentence (or remove it) so users are not mis-led when debugging API failures.

---

54-64: Repeated sentences make the prose look autogenerated.

Three consecutive blocks start with “Raised when …”. Varying the wording (or using a short, single-sentence list style) will read better and avoids the LanguageTool warning in the CI hints.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/task/constants.mdx (1)

6-9: Empty-module notice is fine but consider hiding the page.

If the module truly has no public surface, you may omit it from the sidebar to avoid a “nothing to see here” experience, or generate it only when content exists.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/template/filters.mdx (1)

8-11: Minor completeness nit: list functions/constants too.

infrahub_sdk.template.filters also exports helper functions alongside FilterDefinition. Including them will give users a full view of the module.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/constants.mdx (1)

8-11: Add the enum members for real usefulness

The page stops at the class heading; without listing InfrahubClientMode members (e.g., SYNC, ASYNC, …) consumers still have to open the source. Consider appending a fenced block or a bullet list enumerating the available modes.

 ### `InfrahubClientMode` …</sup>

+```python
+class InfrahubClientMode(Enum):
+    SYNC = "sync"
+    ASYNC = "async"
+```
+
+| Member | Meaning |
+| ------ | ------- |
+| `SYNC` | Blocking client that executes operations synchronously. |
+| `ASYNC`| Non-blocking client using asyncio under the hood. |

docs/docs/python-sdk/sdk_ref/infrahub_sdk/repository.mdx (1)

16-24: Link the Repo return type to its origin for clarity

Repo comes from gitpython. A quick hint prevents readers from guessing.

 ```python
 initialize_repo(self) -> Repo

+Repo refers to git.Repo from the GitPython package.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/task/exceptions.mdx (1)</summary><blockquote>

`8-16`: **Provide one-line descriptions for each exception**  

Listing names alone forces readers into source code. Add a short rationale per exception.

```diff
 ### `TaskError` …</sup>
+Generic base class for all task-related errors.
 
 ### `TaskNotFoundError` …</sup>
+Raised when a task with the requested ID does not exist.
 
 ### `TooManyTasksError` …</sup>
+Thrown when a query returns more tasks than expected or allowed.
 
 ### `TaskNotCompletedError` …</sup>
+Indicates that an awaited task is still in progress.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/node/attribute.mdx (1)

18-28: Avoid duplicate headings for the value property

Two separate “value” entries are rendered – one for the getter and one for the setter – but both appear as ordinary methods. This is slightly confusing because the implementation is actually a @property with a corresponding @value.setter.

Consider collapsing them into a single heading (e.g. “value property”) and, inside that section, documenting the getter / setter behavior.
That keeps the reference concise and avoids giving the impression that two overloads must be called directly.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/exceptions.mdx (1)

10-16: Generic base class name may cause ambiguity

Using an unconstrained name like Error for the project’s base exception can be confusing when scanning stack traces – it conveys almost no project context.
Unless this is locked in by API guarantees, consider renaming to something that is immediately recognisable, e.g. InfraHubError.

docs/src/theme/MDXComponents.js (1)

4-10: Minor inconsistencies & bundle-size consideration

1. The comment says “available in MDX as <icon />”, but the export key is Icon, so usage will actually be <Icon />.
   Update the comment to avoid confusion.

2. The remark “Import the entire Iconify library” is slightly misleading – @iconify/react only ships the Icon component wrapper, not every icon.
   Still, including Iconify can noticeably increase the docs bundle. If bundle size becomes an issue, look at:

   • @iconify/react/dist/iconify/icon.js (tree-shakable subset)
   • Dynamic imports for rarely-used icons.

-import { Icon } from '@iconify/react'; // Import the entire Iconify library.
+import { Icon } from '@iconify/react'; // Makes <Icon /> available in MDX.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/data.mdx (1)

8-18: Add concise class & method summaries to improve usability

The page lists RepositoryBranchInfo, RepositoryData, and get_staging_branch, but provides no short explanation of what each class / method represents or when to use it. A one-sentence summary under every heading dramatically improves discoverability when browsing the generated sidebar.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/groups.mdx (1)

8-14: Document parameters & return value

group_add_subscriber exposes four parameters and a dict return type, yet no information is given about expected shapes (e.g. subscriber list contents, branch semantics, structure of the returned dictionary). Consider adding a short “Parameters / Returns” block.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/template/models.mdx (1)

8-10: Missing class description

UndefinedJinja2Error is listed without context. Including what triggers this error and typical handling guidance would save users a round-trip to the source.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/generator.mdx (1)

16-20: Return type None may hide useful output

If list_generators prints to stdout rather than returning data, note this explicitly; otherwise consider returning the list so callers can programmatically consume it.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/node/parsers.mdx (1)

10-14: Provide examples for tricky parsing rules

parse_human_friendly_id is central to node look-ups but the docs lack concrete examples (e.g. 'user:john.doe' -> ('user', ['john', 'doe'])). Two or three examples would make the behaviour immediately clear.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/task/models.mdx (1)

10-17: Avoid hard-wiring the main branch in GitHub source links

The generated links point explicitly to …blob/main/….
If users browse a versioned site (e.g. a tagged release or an older branch), the links will always jump to main, which may no longer match the rendered signature.

Prefer injecting the current commit SHA (or the branch/tag used during doc build) so the source link always reflects the exact code that was documented.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/client.mdx (1)

12-20: Consider shortening long signatures for readability

Very long one-liners tend to wrap in narrow view-ports and hurt readability.
A common pattern is:

```python title="signature"
initialize_client(
    branch: str | None = None,
    identifier: str | None = None,
    …
) -> InfrahubClient

Not mandatory, but improves UX.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/transfer/importer/interface.mdx (1)</summary><blockquote>

`10-18`: **Minor style nit – add back-ticks around parameter types**

For consistency with other auto-generated pages, wrap type names in ``` `Path` ``` and ``` `str` ``` inside the signature so they render monospace.

Purely cosmetic.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/async_typer.mdx (1)</summary><blockquote>

`12-30`: **Add concise descriptions & param/return details for each method**  
Right now the section lists the signatures only. A one-line summary plus an *Args / Returns* block would make the generated docs far more useful to readers skimming for behaviour, without having to open the source link each time.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/object.mdx (1)</summary><blockquote>

`10-37`: **Document parameters, options, and possible errors**  
`load`/`validate` expose several Typer options (`paths`, `debug`, `branch`, config param) but the reference omits any explanation of what they do or which CLI flags map to them. Adding a short bullet list (and mentioning raised exceptions) would align this page with the rest of the ctl docs and help CLI users quickly understand usage.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/render.mdx (1)</summary><blockquote>

`10-20`: **Include purpose/usage examples for helper utilities**  
Both `list_jinja2_transforms` and `print_template_errors` are utility helpers whose usefulness is not obvious from the signature alone. A two-sentence description or minimal code snippet (e.g. how to call them from a script) would greatly improve discoverability.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/menu.mdx (1)</summary><blockquote>

`10-37`: **Provide argument descriptions for consistency with other ctl pages**  
The `menus`, `debug`, `branch`, and config arguments are undocumented here, whereas parallel pages (e.g. *branch*, *object*) include at least a brief explanation. Adding those keeps the generated reference consistent and avoids reader confusion.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/transfer/schema_sorter.mdx (1)</summary><blockquote>

`12-18`: **Explain the return structure of `get_sorted_node_schema`**  
The method returns `list[set[str]]`, but the semantics (order guarantees, meaning of the inner sets) are not described. A short *Returns* section clarifying this would prevent misuse.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/types.mdx (2)</summary><blockquote>

`20-56`: **Avoid repetitive phrasing in method descriptions**

Six consecutive method descriptions start with “Send a … event.” Language-Tool rightfully flags the repetition; varying the phrasing or dropping the verb entirely (“Debug event”, “Info event”, …) makes the page read less mechanical.

No functional impact, but quick to improve user experience and perceived polish.

---

`10-18`: **Missing class summaries**

Only the header and GitHub link are rendered for each class (`HTTPMethod`, `RequesterTransport`, …) without even a one-line synopsis of what the class represents. Readers landing here have to click through to source to know if they’re in the right place.

If docstrings exist, configure `mdxify` to emit the first sentence; otherwise add a terse manual summary.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/spec/menu.mdx (1)</summary><blockquote>

`10-34`: **Add brief descriptions for new classes**

`InfrahubMenuFileData` and `MenuFile` headers render without any explanatory text. Even a single sentence lifted from the class docstring (e.g., “Pydantic model for menu-spec files”) helps give context.

</blockquote></details>
<details>
<summary>docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/exceptions.mdx (1)</summary><blockquote>

`10-15`: **Refine base-exception description**

The sentence “pytest-infrahub Base exception.” reads awkward. Consider:  

```diff
-pytest-infrahub Base exception.
+Base class for all pytest-infrahub exceptions.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/plugin.mdx (1)

10-32: Prefer commit-pinned GitHub permalinks instead of main branch anchors

All source links target .../blob/main/...#LXX.
If the file later changes, the line anchors will drift and the link will drop the visitor in the wrong place.
Using a short (or full) commit SHA in the URL guarantees the anchor always resolves to the exact line that was documented.

Example:

-https://github.com/opsmill/infrahub-sdk-python/blob/main/infrahub_sdk/pytest_plugin/plugin.py#L15
+https://github.com/opsmill/infrahub-sdk-python/blob/<COMMIT_SHA>/infrahub_sdk/pytest_plugin/plugin.py#L15

mdxify supports injecting the current git SHA; if it is not already available, consider extending the generator (or a post-processing step) to rewrite the links.
This is cosmetic but avoids subtle “where am I?” moments for readers.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/yaml.mdx (1)

10-88: Stabilise source links with commit SHAs

Same remark as for pytest_plugin/plugin.mdx: every anchor relies on the mutable main branch.
Pinning to a commit (or tag) removes the risk of stale / shifted anchors when the file evolves.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/validate.mdx (1)

20-35: Long signature is hard-wrapped; consider breaking lines for readability

The rendered MDX line for validate_graphql is >180 chars which makes horizontal scrolling likely on smaller view-ports.
mdxify can insert \ line continuations or wrap the parameters on multiple lines inside the code block to improve readability without affecting copy-paste:

-validate_graphql(query: str, variables: Optional[list[str]] = typer.Argument(None, help='Variables to pass along with the query. Format key=value key=value.'), debug: bool = typer.Option(False, help='Display more troubleshooting information.'), branch: str = typer.Option(None, help='Branch on which to validate the GraphQL Query.'), _: str = CONFIG_PARAM, out: str = typer.Option(None, help='Path to a file to save the result.')) -> None
+validate_graphql(
+    query: str,
+    variables: Optional[list[str]] = typer.Argument(
+        None,
+        help='Variables to pass along with the query. Format key=value key=value.',
+    ),
+    debug: bool = typer.Option(False, help='Display more troubleshooting information.'),
+    branch: str = typer.Option(None, help='Branch on which to validate the GraphQL Query.'),
+    _: str = CONFIG_PARAM,
+    out: str = typer.Option(None, help='Path to a file to save the result.'),
+) -> None

Minor, but it noticeably boosts legibility.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/testing/docker.mdx (1)

10-36: Consistent return-type wording

skip_version already states “Check if a test should be skipped…”.
For client / client_sync, adding a one-liner (“Return an async/sync Infrahub client bound to the running Docker instance.”) would align with the concise descriptive style used elsewhere and give context to newcomers skimming the docs.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/testing/repository.mdx (1)

18-46: Missing short descriptions for methods

Each method is listed with its signature but no accompanying description, unlike other sections (e.g., skip_version). Adding a sentence or two explaining what the method does (not just how) will make this page self-contained and quicker to digest.

Example:

#### `repo`
Return the underlying `GitRepoManager` instance handling low-level git operations.

Auto-generation could pull the method docstring when available.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/transforms.mdx (1)

41-44: Replace “check” with “transform” to avoid confusion

The sentence still talks about “the result of the check”; this looks like a copy-paste from the checks docs and is misleading in the context of a transform.

-The result of the check is determined based on the presence or not of ERROR log messages.
+The result of the transform is determined based on the presence or absence of ERROR log messages.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/config.mdx (1)

57-63: Parameter name, default value and typo are inconsistent with the signature

1. The docstring refers to config_file_name, but the actual parameter is config_file.
2. Default file in the signature is infrahubctl.toml, while here it states pyprojectctl.toml.
3. Typo: ValidationErorr → ValidationError.

-This is done to handle a ValidationErorr which is raised when settings are specified but invalid.
+This is done to handle a ValidationError which is raised when settings are specified but invalid.
@@
-**Args:**
-- `config_file_name`: [description]. Defaults to "pyprojectctl.toml".
+**Args:**
+- `config_file`: Path to the TOML configuration file. Defaults to "infrahubctl.toml".

docs/docs/python-sdk/sdk_ref/infrahub_sdk/uuidt.mdx (1)

40-41: Nit: “digit” → “digits”

Minor grammar improvement.

-Return the last 8 digit of the UUID (the most random part)
+Return the last 8 digits of the UUID (the most random part)

tasks.py (1)

276-282: Consider improving error handling specificity.

The current error handling catches UnexpectedExit with exit code 127, but the error message specifically mentions Python version compatibility. Consider making the error message more generic or checking for other potential causes.

         except UnexpectedExit as e:
             if e.result.exited == 127:
                 print(
-                    " - mdxify is not installed, probably due to the python version being outside its supported range."
+                    " - mdxify is not available. This could be due to it not being installed or Python version compatibility issues."
                 )
+            else:
+                print(f" - mdxify failed with exit code {e.result.exited}")
             sys.exit(1)

docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/items/graphql_query.mdx (1)

10-12: Avoid hard-coding branch & line numbers in GitHub permalinks

Every link points to .../blob/main/...#Lxx.
As soon as the source file changes, these anchors will drift and the docs will lead to incorrect code lines.
Generate links against a commit SHA (permalink) or drop the #Lxx fragment entirely to avoid link-rot.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/branch.mdx (2)

72-80: Document states “NOT IMPLEMENTED YET” – flag clearly as TODO

The validate function description advertises behaviour that is “NOT IMPLEMENTED YET”.
Mark this explicitly with a TODO or @experimental badge so users don’t assume the feature works today.

---

35-36: Signature lines are extremely long – consider line-wrapping for readability

Long, unwrapped signatures render poorly on narrow viewports and mobile docs.
Have the generator insert line breaks after each argument.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/topological_sort.mdx (1)

24-32: Missing mention that functions raise DependencyCycleExistsError

topological_sort and get_cycles raise DependencyCycleExistsError, but the docs for those functions don’t reference this exception.
Add a “Raises” section so users know which errors to catch.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/exporter.mdx (1)

18-20: Excessively long function signature hampers readability

The dump signature is 350+ characters. Break each parameter onto its own line for easier scanning and to avoid horizontal scrolling.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/schema.mdx (1)

20-32: Add minimal descriptions for undocumented functions

Several functions (validate_schema_content_and_exit, display_schema_load_errors, handle_non_detail_errors, …) lack any descriptive text after the code block, unlike callback, load, and check. Including one-liner summaries (even if copied from the docstring) greatly improves the generated reference usability.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/models.mdx (1)

14-22: Document key class attributes / behaviours

InfrahubBaseTest, InfrahubInputOutputTest, etc., are top-level abstractions but their purpose is unclear without any narrative. Consider inserting a short paragraph before the Methods list explaining the role of each class (e.g., “Base class for …”, expected usage, important attributes).

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/check.mdx (1)

60-63: Missing explanation for CheckModule

CheckModule is listed under Classes without any description or method list, unlike the functions above. Either omit the heading or add at least a short summary and public attributes/methods so readers know how to use it.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/items/jinja2_transform.mdx (1)

32-38: Consider collapsing repetitive method stubs into tables

The current layout shows many short code blocks that only repeat the signature. For long pages, converting these into a single markdown table (Method | Return type | Description) cuts vertical scroll and improves scannability.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/schema/main.mdx (1)

6-8: Consider adding an “Enums” subsection for clarity
Several entities listed below (RelationshipCardinality, BranchSupportType, …) are enumerations, not classes. Grouping them under a dedicated “## Enums” header makes the doc easier to scan.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/task/manager.mdx (1)

51-56: Parameter name shadows Python built-in filter
The generated signature shows a parameter called filter. In the code this shadows Python’s built-in filter() and may confuse users or tooling. Consider renaming the argument (e.g. filters) in the source to avoid the clash; the docs will follow automatically on next generation.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/pytest_plugin/items/base.mdx (1)

61-65: Spelling: “absolut” → “absolute”

-This will be an absolute path if --infrahub-config-path is an absolut path as happens when
-tests are started from within Infrahub server.
+This will be an absolute path if `--infrahub-config-path` is an absolute path, as happens when
+tests are started from within the Infrahub server.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/node/related_node.mdx (1)

68-72: Minor style: Avoid passive voice in class description
“Represents a RelatedNodeBase in an asynchronous context” reads clearer as “Asynchronous wrapper around RelatedNodeBase”.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/batch.mdx (1)

30-33: Remove the double blank line to satisfy markdown-lint (MD012)

Two consecutive blank lines are present, triggering the CI markdown-lint failure.

-Executes the stored task.
-
-
+Executes the stored task.
+

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/repository.mdx (2)

29-32: Tighten wording of the module overview

The sentence ends with a double‐dot ellipsis and does not actually mention the object (“repositories”) it refers to.

-Manage the repositories in a remote Infrahub instance.

-List, create, delete ..
+Manage repositories in a remote Infrahub instance.

+List, create and delete repositories.

---

36-38: Hide internal “_” parameter from the docstring

_: str = CONFIG_PARAM is an internal Typer context parameter and adds noise to the public API reference.
Consider excluding it during generation (e.g. via :exclude-members: or a custom mdxify filter).

docs/docs/python-sdk/sdk_ref/infrahub_sdk/graphql.mdx (1)

16-21: Correct the type annotation for render_variables_to_string

dict[str, type[str | int | float | bool]] is not valid Python typing and may confuse readers.

-render_variables_to_string(data: dict[str, type[str | int | float | bool]]) -> str
+render_variables_to_string(data: dict[str, str | int | float | bool]) -> str

Ensure the source annotation in infrahub_sdk/graphql.py matches this correction so that the next doc-generation run stays consistent.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/utils.mdx (2)

103-107: Bullet list formatting is off

The three lines are intended as list items but render as plain text. Prefix them with “- ” to display properly.

- the intersection of both
- the item present only in list1
- the item present only in list2
+ - the intersection of both
+ - the item present only in list1
+ - the item present only in list2

---

216-218: Typo: “seam” → “seem”

-This implementation may seam counter intuitive but in the current implementation
+This implementation may seem counter-intuitive, but in the current implementation

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/utils.mdx (1)

23-23: Fix typo & tighten wording

exeception → exception, and use the adverb “differently” to avoid verbosity.

-Handle exeception in a different fashion based on its type.
+Handle exceptions differently based on their type.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/branch.mdx (1)

23-24: Remove extra blank line to satisfy markdown-lint MD012

-
-
+

docs/docs/python-sdk/sdk_ref/infrahub_sdk/store.mdx (1)

43-47: Polish phrasing for conciseness.

The introductory sentence is verbose; tightening it improves readability without losing meaning.

-Internal Store for InfrahubNode objects.
-
-Often while creating a lot of new objects,
-we need to save them in order to reuse them later to associate them with another node for example.
+Internal store for InfrahubNode objects.
+
+When creating many new objects, we often need to keep them so they can be reused later—for instance, when associating them with another node.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/operation.mdx (2)

29-31: Clarify activation wording for store

“The store will be populated … if activated” is a bit vague. Consider a wording that specifies the flag/mechanism that enables population so that users know exactly what to set.

-The store will be populated with nodes based on the query during the collection of data if activated
+The store is populated with nodes that match the query **when `populate_store=True` in the collection API**

---

38-47: Differentiate nodes() vs related_nodes()

Both descriptions are identical, leaving readers unsure about the distinction between the two helpers.
Add a brief sentence highlighting what qualifies a node as “related” (relationship traversal depth, direction, etc.) or remove one if they are aliases.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/testing/schemas/animal.mdx (1)

38-43: Provide high-level purpose for schema_base

schema_base is central to the class but the docstring is empty. Adding a one-liner (e.g. “Composes the root schema from all node-specific fragments”) helps newcomers understand why they would call this helper.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/node/node.mdx (1)

165-170: Fix grammar & indentation in generate_query_data_node args list

Minor markdown glitches make the bullet list hard to read:

- - `inherited`: Indicated of the attributes and the relationships inherited from generics should be included as well.
-                       Defaults to True.
+ - `inherited`: Whether attributes/relationships inherited from generics are included (default **True**).

Also out-dented continuation lines so bullets render correctly.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/client.mdx (1)

94-112: Collapse overloaded signatures to reduce noise

The four consecutive create(...) overloads make the page extremely long and difficult to scan.
Consider configuring mdxify to hide duplicated overloads behind a collapsible section or keep only the most generic signature.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/config.mdx (1)

51-60: Typo & argument-name mismatch

1. ValidationErorr is misspelled.
2. The Args section refers to config_file_name, but the signature exposes config_file.

-This is done to handle a ValidationErorr which is raised when settings are specified but invalid.
+This is done to handle a ValidationError which is raised when settings are specified but invalid.
@@
-• `config_file_name`: [description]. Defaults to "pyprojectctl.toml".
+• `config_file`: [description]. Defaults to "infrahubctl.toml".

docs/docs/python-sdk/sdk_ref/infrahub_sdk/client.mdx (1)

505-515: Duplicate typo in sync-client section

Same typo as above appears in the synchronous execute_graphql description.

-If retry_on_failure is True, the query will retry until the server becomes reacheable.
+If `retry_on_failure` is `True`, the query will keep retrying until the server becomes reachable.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/types.mdx (1)

24-68: Consistent punctuation for method descriptions
debug, info, warning, critical, and exception end their description sentences without a period, whereas error ends with one. Use a uniform style for all six docstrings.

-Send a error event.
+Send an error event

…and either add or remove the trailing period on the other five lines to match.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/exceptions.mdx (1)

50-57: Duplicate description – consider removing one
InvalidResponseError (L54-56) repeats exactly the text already used for UninitializedError (L50-52). Either adjust the wording or remove the duplicate to avoid confusion.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/utils.mdx (1)

148-154: Minor grammar / wording fixes

1. If branch isn't provide ➜ If a branch isn't provided
2. may seam counter intuitive ➜ may seem counter-intuitive
3. Currently the function support ➜ Currently the function supports

-If branch isn't provide, return the name of the local Git branch.
+If a branch isn't provided, return the name of the local Git branch.

-This implementation may seam counter intuitive but in the current implementation
+This implementation may seem counter-intuitive, but in the current implementation

-Currently the function support Fields and InlineFragments but in a combined tree
+Currently the function supports Fields and InlineFragments but in a combined tree

Also applies to: 186-192

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/utils.mdx (1)

22-23: Simplify wording for clarity

-Handle exception in a different fashion based on its type.
+Handle exceptions differently depending on their type.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/store.mdx (2)

42-46: Grammar tightening for the introductory paragraph

Minor wording improvements for clarity & conciseness.

-Internal Store for InfrahubNode objects.
-
-Often while creating a lot of new objects,
-we need to save them in order to reuse them later to associate them with another node for example.
+Internal store for `InfrahubNode` objects.
+
+When creating many new objects, we often need to save them so they can be reused later—for example, to associate them with another node.

---

60-100: Consider collapsing the overload explosion for NodeStore.get

Eight consecutive overload signatures make the doc noisy and push relevant content far below the fold. A single canonical signature plus a table/paragraph explaining the parameter permutations would be easier to read and maintain.

This is purely a docs-generation choice (mdxify supports signature suppression/merging).
If you keep the current layout, expect frequent diffs when line numbers drift, increasing CI churn.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/client.mdx (1)

258-268: Fix typo “reacheable” → “reachable”

-If retry_on_failure is True, the query will retry until the server becomes reacheable.
+If `retry_on_failure` is `True`, the query will keep retrying until the server becomes reachable.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

docs/docs/python-sdk/sdk_ref/infrahub_sdk/types.mdx (2)

8-18: Add class-level descriptions for better usability

Only InfrahubLogger contains a description; every other class is listed without any context. Readers landing on this page have no idea what a SyncRequester, Order, etc. represent. Please generate at least a one-liner per class – you already have the source links so a short summary is easy to pull from docstrings.

---

54-68: Avoid repetitive “Send a … event.” sentences

Six consecutive method descriptions start with “Send a … event.” and add no real value. Either omit the sentence (the method name is self-explanatory) or replace it with specific behaviour notes (e.g. “Logs at DEBUG level through the configured Infrahub logger”).

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/config.mdx (1)

56-60: Parameter names do not match the actual signature

The Args section lists config_file_name, while the signature is load_and_exit(..., config_file='infrahubctl.toml', ...). Please update the parameter list to match the code or the generated docs will mislead users.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/exceptions.mdx (1)

30-38: Document intent for exceptions that only have a name

Many exceptions (e.g. SchemaNotFoundError, ModuleImportError) are listed with zero description. A single-sentence rationale (“Raised when …”) greatly improves searchability and DX. Consider pulling the first line of each class docstring into the MDX.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/utils.mdx (2)

188-192: Typo: “seam” → “seem”

-This implementation may seam counter intuitive
+This implementation may seem counter-intuitive

---

226-229: Minor wording

“between a timedate in string format and now.” → “between a date-time string and now.”

docs/docs/python-sdk/sdk_ref/infrahub_sdk/ctl/utils.mdx (1)

22-24: Tighten phrasing

“Handle exception in a different fashion based on its type.” → “Handle exceptions differently depending on their type.”

docs/docs/python-sdk/sdk_ref/infrahub_sdk/store.mdx (1)

44-45: Streamline wording for better readability

The phrasing is a bit verbose and uses the patterns “a lot of” / “in order to”, which can be tightened up.

-Often while creating a lot of new objects,
-we need to save them in order to reuse them later to associate them with another node for example.
+Often when creating many new objects, we need to persist them so they can be reused later—for example, to associate them with another node.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/client.mdx (2)

258-259: Fix typo “reacheable” → “reachable”

-If retry_on_failure is True, the query will retry until the server becomes reacheable.
+If `retry_on_failure` is **True**, the query will retry until the server becomes **reachable**.

---

504-505: Same typo re-appears – correct it here as well

-If retry_on_failure is True, the query will retry until the server becomes reacheable.
+If `retry_on_failure` is **True**, the query will retry until the server becomes **reachable**.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

docs/docs/python-sdk/sdk_ref/infrahub_sdk/client.mdx (2)

414-416: Copy-paste artefacts leak into IP-prefix docs

Same pagination wording is repeated here; fix as in previous comment.

---

736-739: Sync allocate_next_ip_address docs – incorrect parameter details

Replicate the correction applied to the async variant for timeout, tracker, and raise_for_error.

docs/docs/python-sdk/sdk_ref/infrahub_sdk/client.mdx (4)

34-44: Duplicate request_context entries create noise

Both the getter and the setter show up under the exact same heading. Consider renaming one of the headings (e.g. “request_context ‑ getter” / “request_context ‑ setter”) or grouping them in a single section to avoid reader confusion.

---

88-105: Overload explosion – collapse identical create() signatures

Seven overload blocks are rendered back-to-back, yet only two logical variants exist (“kind as str” and “kind as SchemaType”). The current dump overwhelms the page and makes the real API harder to grasp.

Diff-style proposal (keep only meaningful variants – pseudo code):

-### `create`
-```python
-create(self, kind: str, data: dict | None = ..., ...)
-```
-### `create`
-```python
-create(self, kind: type[SchemaType], data: dict | None = ..., ...)
-```
-...
+### `create`
+```python
+create(
+    self,
+    kind: str | type[SchemaType],
+    data: dict | None = None,
+    *,
+    branch: str | None = None,
+    timeout: int | None = None,
+    **kwargs: Any,
+) -> InfrahubNode | SchemaType
+```

This reduces clutter while fully describing the callable.

---

259-259: Spelling: “reachable”

reacheable → reachable.

---

505-505: Spelling: “reachable” (sync variant)

reacheable → reachable.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro